Software programs sometimes need to be patched (e.g., to correct an error or implement a new feature) after they have been released and are in use. For example, in systems in which functions, portions of functions or other code segments have been compiled into binary code representations of these functions or code segments, the compiled code sometimes need to be replaced with new code that is compatible with the old code and its data structures. A code patching operation sometimes includes the insertion of code (sometimes referred to as a redirection patch) that redirects execution from one sequence of instructions to another. Some existing techniques for performing binary patching require that all running threads of an executing program are halted while such a code patching operation is performed, e.g., in order to ensure that they are not affected by the patching.
In addition, prior to performing a code patching operation, some existing binary patching techniques must analyze the instruction stream as well as various call stacks and/or other runtime data structures in order to determine whether a code patching operation can be performed without breaking the program being patched. For example, the code patching operation may not be able to be performed if it cannot be determined that there are no entry points within the code being patched for which a return or jump to that entry point prior to completing the patch operation or following the completion of the patch operation will result in incorrect or invalid behavior (e.g., due to an intermediate state that includes an invalid combination of instructions and/or arguments). Some instruction set architectures include instructions of variable lengths, meaning that it may not even be clear where all of the instruction boundaries (and, thus the entry points) in the program being patched are located, which can make such an analysis even more difficult, time consuming, and (in some cases) prone to error.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that the embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.